BBS Toolkit/BBS Toolkit.iso/gt_power/gttutors.zip/GTTUTOR6.TXT

Text File | 1987-11-09 | 19KB | 330 lines

This tutorial is about the newest feature of GT Power, EchoMail.  It is
not intended to be considered an exhaustive study of the subject, but it
should be sufficiently detailed to help the vast majority of readers to
understand what it is, how it works, and how to set it up.

First, as usual, some definitions.

Netmail:  Whenever used in this tutorial, Netmail refers to the function
available to registered GT Power users.  It is not meant to include any
other form of electronic message switching or E-Mail services, and it
certainly does not mean to suggest that the programs associated with GT
Power that perform these functions are in any way compatable with any
other such service.  As of this writing, 11/08/87, there is no such
compatability.  (See GTTUTOR5.TXT for a fairly complete discussion of
Netmail).

Echomail:  An extension of Netmail that allows message files to be
replicated on other systems.  That is, a particular message base, known
as the Hub or Sponsoring base, is the end of a set of chains (Net/Nodes)
and any messages placed into that message base will be copied (via
Netmail) to similar message bases on all 'Subscribing' systems.
Further, that same message base may have messages added to it by any of
those Subscribing systems and these messages will also ultimately be
strewn throughout the set of subscriber systems after they have found
there way to the Sponsoring message base.  These ideas will be far
better explained as you read on.

Sponsoring message base:  This is the set of messages which reside on
the system that creates the conference.  For example, the National
Echomail Conference that deals with Financial issues is located on the
system located at Net/Node 001/000.  The Sysop of that system, myself,
has agreed to 'Sponsor' this conference and, thus, created the message
base and let its existence be known throughout the Network.  In order to
become a Sponsor you must establish a unique Net/Node address that
represents your conference, and publish that address so that others may
know about it.  In the case of the National Echomail conferences,
you must have this Net/Node address assigned to you by the National
Echomail coordinator.  Local Echomail conferences, (those available to
only your Net, for example), are assigned identifiers by the local
Echomail coordinator.  These Echomail Net/Node numbers are in addition
to the normal Netmail Net/Node address that is assigned to your system
and they always begin with the letter 'E'.

Subscriber message base:  Any node on the Network may become a
'Subscriber' to any and all conferences which they are made aware of.  A
subscribing message base is a copy of the Sponsoring message base in
that it is created for that purpose and its contents come from Netmail
contact with another system that is either a subscriber or sponsor of
the conference.  In order to become a subscriber, you need only
establish entries in your ROUTING.BBS file that properly identifies the
conference and which point to a source Net/Node from which to get that
conference updated via Netmail.  Each Echomail conference has a unique
identifier as described above.  For example, the National Finance
conference is identified as conference E00/003.

Public access:  Netmail, and of course, by extension, Echomail, is NOT a
public service.  It is a function of GT Power that is available to
registered users and their authorized guest users.  Further, just
because you have access to the Netmail/Echomail code does not mean that
you automatically have access to the International Netmail Network, or
to any Echomail conferences that are on that Network.  Instead, access
to a Network (National, Local, or private) requires that you have been
issued an enabling CRC and a unique Net/Node address that identifies
your system to all others that are on the Network in question.  The
assignment of a Net/Node and a CRC is not automatic, nor is it a 'right'
belonging to all registered users of GT Power.  It is the right of the
Network coordinators to exclude or authorize whomever they wish to these
services.  While access is generally not denied to anyone that applies,
such denial is possible.  Similarly, access to a particular Echomail
conference is neither automatic nor is it a 'right'.  In the case of
National Echomail conferences, access is accomplished rather easily and
without prior authorization.  The nature of the National conferences is
such that they may be accessed by any existing Netmail Net/Node that has
not been specifically excluded by the sysop of a system that the
'subscriber' wishes to obtain access to the conference from.  Since
there are many alternatives to choose from, each providing access to the
same message base, this is effectively the same as saying that anyone
that is authorized to use the National Network may access any National
conference.

All of which is to say that these conferences are easily joined, but
they are NOT PUBLIC SERVICES.  However, as it would make no sense,
whatever, for private messages to be distributed across the systems of
all subscribers to these conferences, YOU MAY NOT HAVE ANY PRIVATE
MESSAGES IN AN ECHOMAIL CONFERENCE.  Indeed, Netmail/Echomail prevents
you from doing so.

Chains of Subscribers:  While there may be only one Sponsoring message
base, there may be any number of Subscribers and, thus, any number of
copies of that message base.  Since Subscribers may obtain access to the
conference by connecting either with the Sponsoring system or that of
any other subscriber, you can see that an Echomail conference will
consist of some number of chains of subscribers.  Whenever messages are
added to the Sponsoring message base they will be made available to any
subscriber that should call the sponsoring system as of the next Netmail
session hosted by that Sponsor.  Once these messages are received into
the subscriber's conference message base they may be obtained by any
other subscriber that calls that system, but usually there will be a one
day delay in such availability.  Thus, the farther down a particular
chain you are, the less current will be your conference, but they will
always be complete up to the last update they receive.  Delays of a day
or two or three are normal and expected in Echomail conferences.  Should
a chain be 'broken' for any reason, any subscriber downstream may
reestablish the conference by connecting with any other subscribing
system that is upstream (closer to the Sponsor).  In doing this there
will be NO LOSS in terms of the contents of the conference once the
chain is reestablished.  This is because Echomail will automatically
determine the date of the last update to a subscriber's conference and
provide all messages subsequent to that update.

What is not obvious so far is that if you should try to reestablish a
broken chain by connecting to a system that was downstream rather than
upstream relative to yourself, then you will have established a closed
loop conference that will no longer be able to obtain updates from the
sponsor.  Great care must be taken to insure that all subscribers are
always connecting to either an upstream subscriber or to one that is
subscribing via a different chain than was previously in existence.
Said differently, you must NOT allow a circular path, closed loop, to exist.

Directories:  Echomail uses normal Netmail directories (\MAILOUT,
\MAILIN, and \MAILWORK).  What it does NOT use are Netmail message
bases!  All Echomail conferences are normal 'vanilla' message bases.
These message bases are usually set up to preclude private messages (via
placing a carrot (^) at the beginning of the message base pathname in
GTMDIR.BBS), but they NEVER are to include the Netmail symbol (~) as
part of their pathname.

There is only one semi-official Echomail file: ECHOMAIL.BBS.  This file
is not in any way necessary for the operation of Echomail.  It is merely
a list of the currently available National Echomail conferences, the
Net/Node of the Sponsor of these conferences, and the times of day that
the Sponsoring system is available to receive Echomail calls from
Subscribers.  This list is expected to be updated frequently and made
available from the National Echomail coordinator.

Additional concepts:

From the previous paragraph you may have surmised that Sponsors do not
have any obligation to make calls out to subscribers.  You would be
correct.  Subscribers MUST initiate the request to obtain an update for
each conference of interest.  This request may be done during any
Netmail session, regardless of which side placed the call, if it is a
local call or if it is via PC Pursuit.  (Long distance calls make the
request via a PICKUP OVERRIDE.)

When you first join (subscribe to) a conference, you will not receive
the entire contents of the message base unless it is a relatively new
conference.  The default setup of Echomail provides that a Sponsoring
system will retain only the latest 14 days of updates for distribution.
A Sponsor may elect to save as many or as few days as they wish, but it
is unlikely that they will provide dozens of days of such updates to new
subscribers.

Updates are sent downstream via mailbags with the first letter
containing an 'E' rather than a 'B'.  Receipt of these mailbags causes
them to be placed into both your \MAILIN and \MAILOUT direcotries.
Those that are placed in your \MAILIN directory are subsequently
unbagged into your conference message base and those that are placed
into your \MAILOUT directory are made available to any subscriber who
should call your system and request the conference from you.

Any messages that are created on your system as part of the conference
message base will be bagged by the MBAGGER program and placed into
normal mailbags (beginning with the letter 'B') and sent upstream.
These bags flow upstream until they eventually reach the sponsoring
system at which time they will be unbagged into the sponsors conference
and, thus, become available to all subscribers of the conference with
the next day's Netmail session.  When the messages that originated on
your system finally are sent back to you in an 'E' mailbag, they are
ignored in order to prevent duplicate messages from appearing on your
system.  They will, however, continue to flow downstream and be placed
in each recipient subscriber's conference.  In this way, eventually all
conferences will contain the same messages as all other subscribers.
Note, however, that the sequence of messages in the messages bases will
have significant variances from system to system.  They will, however,
be reasonably associated within date sequence.

Echomail conferences are not available to a subscriber just because his
system is connected to another system via a Netmail session.  That is,
the transfer of messages (mail) usually has high priority over the
transfer of Echomail conferences since Echomail conferences can be
delayed by up to 14 days without meaningful loss.  Mail, on the other
hand, must be transferred as expeditiously as possible.  For this
reason, there is a facility within the code to allow Echomail conference
requests to be honored only between certain times of the day.  For
example, suppose that a sponsoring system runs Netmail code from 3:15
a.m. until 5:00 a.m. every day.  Further, suppose that Netmail message
transfers are scheduled to run from 4:00 a.m. until 5:00 a.m.  This
means that Echomail should be made available to subscribers from 3:15
until 4:00.  A new entry in the ROUTING.BBS file allows oyu to specify
the hours which your system will honor Echomail requests.  It is a
single line entry in that file which for this example would look like
this:   ECHOMAIL HOURS  3:15 4:00

Obviously, a subscriber MUST find out the Echomail hours provided by the
system he is calling to obtain the desired conference from.  Further, he
must call during those hours.

As an aside, even if Netmail message traffic is scheduled from 4:00
until 5:00 in the morning, in the situation described above, if there is
any mail to be exchanged between the subscriber and the system he is
connecting to, that mail will be transferred between them during the
Echomail call.  In other words, mail transfers will always be made if it
is possible to do so, even if it is not during the scheduled Netmail
'hour'.

Since Echomail is an extension of Netmail which uses the same code, then
how is it that you can place Echomail calls outside of Netmail time
without making calls to systems that do not have echomail conferences?
That is, if you have a mailbag waiting to be sent to someone, unless you
tell Netmail otherwise, it will try to place a call to effect delivery
of that mail.  Thus, you will need to create a separate ROUTING.BBS file
to be used during Echomail times from that which is used during normal
Netmail.  In the Echomail ROUTING.BBS file you are to set ALL NODES that
you are not calling for ECHOMAIL purposes into your INBOUND NODES list.

In your ROUTING INSTRUCTIONS section of the routing files you must place
ACCEPT statements for each conference you are interested in.  Say, for
example, that you are interested in subscribing to National Conferences
E00/003 and E00/006.  Suppose that you determine that a local node on
your Net carries both conferences so you need only to call that one
system in order to subscribe to both.  Supposing that that local system
is Net/Node 006/000, you would place the following two ACCEPT statements
into your ROUTING INSTRUCTIONS section:
   ACCEPT  E00/003-003 -> 006/000
   ACCEPT  E00/006-006 -> 006/000

In this way, Netmail knows that you are subscribing to these conferences
(and that you are NOT the sponsor), and that you wish to obtain the
conferences via calls out to 006/000.  (If you were a conference Sponsor
you would leave off the re-direction information for your conference).

There is only one more thing to do in the routing file.  You must
include an OUTBOUND NODES entry for each conference you are subscribing
to.  You would need to have the following two entries in this case:
   E00/003
   E00/006

Note, it is not enough that you are connected to 006/000 based on one or
the other of these OUTBOUND NODES entries.  Conference requests will be
issued ONLY for those that are specifed with an entry.  That is, having
E00/003 as an OUTBOUND NODE will cause your system to call and connect
with 006/000, but it will NOT cause a request for E00/006 to be issued
unless there is also such an OUTBOUND NODE specified.

One more new section is now of importance to you.  It is called the
MESSAGE DISTRIBUTION section.  Here is where you tell the MDIST program
what to do with messages that are unbagged by it.  Unless you specify,
all messages are placed into the first Netmail message base listed in
GTMDIR.BBS.  Echomail must be sent to the appropriate message bases
instead of to the Netmail message base.  Your entries in this section
would look like this:

    E00/003-003 -> C:\ECHO\FINANCE
    E00/006-006 -> C:\ECHO\SYSOP

where the information to the right of the re-direction symbol is the
pathname of the conference message base.  Thus, all mailbags that are
marked as belonging to E00/003 will be unbagged into messages that are
placed into the C:\ECHO\FINANCE message base.  Recall that these are
just normal message bases, NOT Netmail message bases.

That's about it.  What's next is to determine how to setup so that you
can exchange routing files and support both Echomail and Netmail session
on one system.  This is done, as you must suspect, via scheduled events
and batch files.

In the example I have been creating above, you might have the following
two entries in your SCHEDULE.BBS file to start events:

03:15-03:59 ECHOMAIL
04:00-04:45 NETMAIL

Then, you might create two batch files that look like this:

ECHOMAIL.BAT:

   COPY ROUTING.ECO ROUTING.BBS
   MBAGGER
   MDRIV028 xxxx-xxxx 3:15 04:00

NETMAIL.BAT:

   COPY ROUTING.NET ROUTING.BBS
   MDRIV028 xxxx-xxxx 4:00 5:00
   MDIST

ROUTING.ECO containing the routing file image that has all non-Echomail
Net/Nodes specified as INBOUND NODES and ROUTING.NET being the routing
file used for normal Netmail.

These two events could just as easily, of course, have been only a
single event and the batch files would be concatenated into a single
file.  Either way is fine, but there are a couple of things you must NOT
DO.

1) Do not allow MBAGGER to run more than once a day (unless you use the
/N option for the second and subsequent times it is run).

2) Do not attempt to run MBAGGER or MDIST programs unless the routing
file contains the appropriate Echomail information.  If you do not have
the MESSAGE DISTRIBUTION section properly setup, then MDIST will not
operate correctly, and the ROUTING INSTRUCTIONS must also be properly
setup for the Echomail conferences.  This argues that whether running
Echomail or just Netmail, the ROUTING INSTRUCTIONS and MESSAGE
DISTRIBUTION sections should be identical.  That is good advice.  Take
it from someone who learned the hard way.

One more thing you should know about Echomail is that it does not
support file transfers.  It would make no sense, whatever, to allow
either File Attach or File Request commands in an Echomail environment.
Though you can create a message that appears to include the .FR or .FA
commands, they will be ignored by the Echomail code.

There is a lot more to know about Echomail, but you now have enough to
get started.  Enjoy the feature and while you are at it, please accept
my invitation to join the National Echomail Finance conference.  As the
Sponsor of this conference, I welcome any comments and observations you
might wish to offer, and invite you to post your thoughts relative to
economic or financial issues in the conference for all who subscribe to
benefit from.

James Davis
National Netmail Coordinator
001/000
Finance Conference Sponsor
E00/003

[phone] - James Davis' Retreat - Houston Texas